home *** CD-ROM | disk | FTP | other *** search
/ InfoMagic Standards 1994 January / InfoMagic Standards - January 1994.iso / inet / ietf / sip / 92nov.min next >
Text File  |  1993-02-17  |  7KB  |  150 lines

  1. Editor's Note: Minutes received 11/20/92
  2.  
  3. CURRENT_MEETING_REPORT_
  4.  
  5.  
  6. Reported by Christian Huitema/INRIA
  7.  
  8. Minutes of the Simple Internet Protocol BOF (SIP)
  9.  
  10. The Simple Internet Protocol BOF attracted a wide audience.  The first
  11. part of the meeting was a quick review of the proposed SIP Charter,
  12. which was approved by the Group modulo alignment of the milestone dates
  13. with the proposed IESG decision schedule.  The participants were
  14. reminded of the name of the mailing list:  <sip-request@caldera.usc.edu>
  15. and that preliminary versions of the documents can be obtained by
  16. anonymous ftp from ``parcftp.xerox.com'' in the directories ``pub/sip''
  17. or ``pub/net-research''.  Related documents on IPAE can be obtained from
  18. the same server in the directory ``pub/ip-encaps''.
  19.  
  20. The discussion turned next to the SIP specifications, addressing a set
  21. of characteristic design points, and in particular some issues that were
  22. marked as provisional in the current specification:
  23.  
  24.  
  25.    o Steve Deering presented a problem posed by the difference between
  26.      the TCP pseudo header ``conceptual layout'' and the actual layout
  27.      of the payload length and type fields in the packets, and asked
  28.      whether conceptual and physical layout should be aligned.  It was
  29.      observed that the pseudo header remains constant (modulo the packet
  30.      length) for the duration of the connection, while changing the
  31.      layout would makes the hop count handling in each packet somewhat
  32.      slower.  Moreover, the relation between packet layout and pseudo
  33.      header will have to remain ``conceptual'' when options like source
  34.      routing are used.  It was decided not to change the packet layout,
  35.      but to explain more clearly the pseudo checksum computation rules
  36.      in the documentation.
  37.  
  38.    o Some Group members questioned the absence of a checksum in the
  39.      network header.  This item had already been debated in the mailing
  40.      list.  The arguments for omitting the checksum will have to be
  41.      presented in detail in a SIP overview document.
  42.  
  43.    o Some Group members questioned the small size of the payload type
  44.      field, and the need to provide an extension mechanism, e.g., for
  45.      student projects.  Various solutions were proposed, e.g., to
  46.      reserve the value ``255'' for an extension mechanism.  The need for
  47.      a payload type indicating ``intermediate options'' (to be processed
  48.      by all routers) was mentioned in the same discussion.  An example
  49.      of a request for such options may be the need of performing ``trace
  50.      route'' on a multipoint address.  This mechanism will have to be
  51.      documented in the specification.
  52.  
  53.    o The discussion on ``flow-ids'' showed that there was no consensus
  54.      on this point that many members feel as deserving further research,
  55.      and that the corresponding bits should remain reserved in the
  56.  
  57.                                    1
  58.  
  59.  
  60.  
  61.  
  62.  
  63.      initial specification.  However, the first implementors reported
  64.      that the presence of a TOS field similar to that of IPv4 would help
  65.      the transition process.  This field will have to be added in the
  66.      revised specification.
  67.  
  68.  
  69. One of the results of the discussions of the specifications was to
  70. outline the need for an ``overview'' document.  The discussion turned
  71. then to addressing.  Ross Callon objected that the 64 bits SIP addresses
  72. were smaller than the 160 bits NSAPs, so could not so easily be used to
  73. incorporate link layer addressing, e.g., telephone numbers.  The
  74. discussion showed that the Working Group did not believe that the NSAP
  75. size was justified or needed, and that there is virtue in keeping the
  76. addresses compact.  Steve Deering presented then the ``metropolitan''
  77. addressing plan.  One of the result of the discussion was to outline
  78. again the need of more explanations.  The overview or the addressing
  79. documents should explain how mobility, renumbering and policy routing
  80. are supported, based on concrete examples.
  81.  
  82. Attendees
  83.  
  84. Cynthia Bagwell          cbagwell@gateway.mitre.org
  85. David Bolen              db3l@ans.net
  86. Ross Callon              callon@bigfut.lkg.dec.com
  87. Ken Carlberg             Carlberg@cseic.saic.com
  88. Stephen Casner           casner@isi.edu
  89. Rob Coltun               rcoltun@ni.umd.edu
  90. Michael Conn             4387451@mcimail.com
  91. Chuck Cranor             chuck@maria.wustl.edu
  92. David Crocker            dcrocker@mordor.stanford.edu
  93. Michael Davis            mad@spirit.clearpoint.com
  94. Steve Deering            deering@parc.xerox.com
  95. Barbara Denny            denny@erg.sri.com
  96. Kurt Dobbins             dobbins@ctron.com
  97. Jon Dreyer               Jon.Dreyer@east.sun.com
  98. Ralph Droms              droms@bucknell.edu
  99. Donald Eastlake          dee@ranger.enet.dec.com
  100. Robert Enger             enger@reston.ans.net
  101. William Fink             bill@wizard.gsfc.nasa.gov
  102. Karen Frisa              karen.frisa@andrew.cmu.edu
  103. Shoji Fukutomi           fuku@furukawa.co.jp
  104. Robert Gilligan          Bob.Gilligan@eng.sun.com
  105. Joseph Godsil            jgodsil@ncsa.uiuc.edu
  106. Masayoshi Gohara         mg@sinet.ad.jp
  107. Heather Gray             heather@zk3.dec.com
  108. William Haggerty         haggerty@ctron.com
  109. Joel Halpern             jmh@network.com
  110. Robert Hinden            hinden@eng.sun.com
  111. Don Hoffman              don.hoffman@eng.sun.com
  112. Christian Huitema        christian.huitema@sophia.inria.fr
  113. John Ioannidis           ji@cs.columbia.edu
  114. Ronald Jacoby            rj@sgi.com
  115. Charley Kline            cvk@uiuc.edu
  116.  
  117.                                    2
  118.  
  119.  
  120.  
  121.  
  122.  
  123. Tracy Mallory            tracym@3com.com
  124. Greg Minshall            minshall@wc.novell.com
  125. Dave Monachello          dave@pluto.dss.com
  126. Andy Nicholson           droid@cray.com
  127. Erik Nordmark            nordmark@eng.sun.com
  128. Joseph Ramus             ramus@nersc.gov
  129. Benny Rodrig             4373580@mcimail.com
  130. Henry Sanders            henrysa@microsoft.com
  131. Henning Schulzrinne      hgs@research.att.com
  132. William Simpson          Bill.Simpson@um.cc.umich.edu
  133. Frank Solensky           solensky@andr.ub.com
  134. Tang Tang                tt@virginia.edu
  135. Richard Thomas           rjthomas@bnr.ca
  136. Jim Thompson             jim@tadpole.com
  137. Stuart Vance             vance@tgv.com
  138. Gregory Vaudreuil        gvaudre@cnri.reston.va.us
  139. A. Lee Wade              wade@nsipo.nasa.gov
  140. Chuck Warlick            warlick@theophilis.nsfc.nasa.gov
  141. Luanne Waul              luanne@wwtc.timeplex.com
  142. Douglas Williams         dougw@ralvmg.vnet.ibm.com
  143. Kirk Williams            kirk@sbctri.sbc.com
  144. Daniel Wilson            dvw@bellcore.com
  145. Robert Woodburn          woody@sparta.com
  146.  
  147.  
  148.  
  149.                                    3
  150.